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2. I consider myself an expert in the art of 
broadcast signal technology. 

3. I have recently studied certain patent application 
file documents for the subject application, which were provided 
to me by the Applicants' legal counsel. These documents include 
copies of the U.S. Patent Application No. 09/076,517 
(hereinafter ''the ^517 Application''), and its U.S. Patent and 
Trademark Office file history, including the March 5, 2002 
Office Action. In that Office Action, Claims 70 and 71 were 
rejected under 35 USC § 112, first paragraph, for the four 
reasons noted at pages 2-3 of the Office Action. 

4. I am informed that the U.S. patent laws require 
that the patent specification contain a written description of 
the invention, and of the manner and process of making and using 
it, in such full, clear, concise, and exact terms as to enable 
any person skilled in the art to make and use the invention. In 
my expert opinion, the ^517 Application provides such a 
description with respect to at least the four points set forth 
in the Office Action, as will be discussed below: 
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5. "An^_Radio" 

It is my expert opinion that the person of ordinary 
skill in the broadcast signal technology art, studying the ^517 
Application, would conclude that, as of the time of the ^517 
Application's filing date, the specification provides proper 
enablement and written description support for the claimed 
feature wherein the claimed audience measurement system applies 
to digital television and radio. 

The reasons for my opinion are as follows. First, 
Page 1, lines 10-11 of the specification clearly discloses the 
monitoring of radio and television signals: "... the addition of 
an identifying code to a radio or television program... 
Second, Applicants have amended the specification at pages 53-54 
to include disclosure from incorporated-by-ref erence U.S. Patent 
No. 5,594,934 [Daozheng Lu, et al.). This disclosure (which I 
understand forms part of the originally filed application) 
clearly teaches that the disclosed audience measurement system 
is for television and radio. 

Finally, the leading business alliance for broadcast 
signals is the National Association of Broadcasters, which 
represents both television and radio broadcasters alike. So, in 
addition to the obvious technical relationship, there is a close 
and obvious business relationship between the two medium. 
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Accordingly, since the ^517 Application discloses the 
monitoring of radio signals at page 1, and since pages 53-54 
provide a detailed discussion of the monitoring of radio 
signals, it is my expert opinion that the person of ordinary 
skill in the broadcast signal technology art would conclude that 
the ^517 Application provides proper enablement and written 
description support for the "and radio" feature in new dependent 
Claim 159. 

6 . " A Control Stream "" 

It is also my expert opinion the person of ordinary 
skill in the broadcast signal technology art, studying the ^517 
Application, would conclude that, as of the time of the ^517 
Application's filing date, the specification provides proper 
enablement and written description support for the claimed 
feature wherein the multiplexed digital data transmission 
includes a control stream having an identification code. 

The reasons for my opinion are as follows. First, the 
^517 Application teaches, in numerous places (such as the 
sentence bridging pages 42-43, the sentence bridging pages 43- 
44, and page 44, lines 14-19), the receiving and processing of 
an ATSC bitstream. The ISO 13818-1:1996 (MPEG-2 Systems) and 
ATSC (Advanced Television Systems Committee) 
Program/Episode/Version Identification Standard (A/57) from 

4 
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August 30, 1996 (both prior to the filing date of the '517 
Application) clearly teach the ordinarily skilled artisan that 
the ATSC bit stream (derived from MPEG-2) includes a control 
stream that has a program identification code. See, for 
example, the attached A/57 document paragraphs 4.2, 4.4, and 
4.5, which refer to a Program Identifier Stream, clearly 
referring to the program identification code in the control 
stream. See also the attached SCTE DVS 136 (published May 5, 
1998) , which specifically refers to a ^'control stream" in 
paragraph G3. Thus, the ordinarily skilled artisan would 
understand the '517 specification as disclosing a control stream 
having an identification code. 

Second, the ^517 Application itself clearly teaches, 
in the paragraph bridging pages 4 6-47, that the software agent 
determines whether a received "data packet has a decodable 
packet label including a decodable program identification code." 
The specification goes on to teach that: "This program 
identification data packet is expected to be a feature in 
digital television programming,../', obviously referring to the 
above-discussed ATSC specification. Clearly, the "control 
stream" is the "data packet" having the "decodable packet label" 
that includes the "program identification code." 

Accordingly, since the ^517 Application clearly refers 
to an ATSC bitstream which is known to have a control stream, 
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and since the ^517 Application itself clearly discloses a ^'data 
packet" having the "decodable packet label" that includes the 
''program identification code", it is my expert opinion that the 
person of ordinary skill in the broadcast signal technology art 
would conclude that the ^517 Application provides proper 
enablement and written description support for the multiplexed 
digital data transmission including a control stream having an 
identification code . 

7 . '' When Reception ... by the Receiver 
Begins " 

It is also my expert opinion that the person of 
ordinary skill in the broadcast signal technology art;, studying 
the ^517 Applica.tion, would conclude that, as of the time of the 
^517 Application's filing date, the specification provides 
proper enablement and written description support for extracting 
the identification code ... when reception of the first (and 
subsequent) channel by the receiver begins. 

The reasons for my opinion are as follows. 

First, extracting program identification information 
"when reception of the channel by the receiver begins" is 
recognized by those of ordinary skill in the art as being part 
of any label acquisition by a receiver, including its 
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application to TV audience measurement systems at the time the 
subject application was filed. For example, the 1987 U.S. 
Patent No. 4,697,209 (David Kiewit and Daozheng Lu, et al.), 
teaches ^'monitoring the on and off and other functions of the 
television receiver" (Column 5, lines 46-49) , and the extraction 
of program identification signatures in response thereto 
(Column4, line 27 through Column 8, line 59). 

Second, the DTV set 110 of Figure 3 obviously includes 
a receiver and runs a software agent 118 to measure audience 
participation. (See Pages 25-26 of the specification.) Page 46 
of the specification teaches that the Figure 7 software agent 
500 can be used for the software agent 118. 

Referring to Figure 7 and the specification at pages 
46-48, when reception by the TV receiver begins, the step 506 
determines whether the data packet has a decodable packet label 
(including a program identification code) . If the data packet 
does not have a decodable packet label (e.g., the TV receiver 
has just been turned ON) , the step 508 logs (records) the TV 
receiver as being ON, and then loops the program back through 
step 506 until a decodable packet label (i.e., one with a 
program identification code) is found. Once found, the program 
proceeds to the step 510 where it is determined whether the 
decodable packet label is the same as the previous one. The 
answer to this step is NO when the TV receiver is first turned 
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ON, and the program then proceeds to step 512 where the program 
identification code is extracted and the corresponding program 
name and time are logged (recorded) . Thus, the program 
identification code in the decodable data packet is extracted 
when the TV receiver begins receiving a first channel. 

Accordingly, since the specification clearly discloses 
the extraction of the identification code when reception of the 
first channel begins, it is my expert opinion that the ^517 
Application provides proper enablement and written description 
support for this claimed feature. 

Returning to Figure 7, when the TV channel is changed, 
the program proceeds through step 506 to step 510, The step 510 
determines that the program identification code in the decodable 
packet label is different from the previous one (before the 
channel was changed) , and proceeds to step 512 where the new 
program identification code is extracted and the new TV program 
name and time are logged (recorded) . Thus, the program 
identification code in the decodable data packet is extracted 
when the TV receiver begins receiving a subsequent channel. 

Accordingly, since the '517 Application clearly 
discloses the extraction of the identification code when 
reception of a subsequent channel by the receiver begins, it is 
my expert opinion that the '517 Application provides proper 
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enablement and written description support for this claimed 
feature also. 

Therefore, it is my expert opinion that the person or 
ordinary skill in the broadcast signal technology art would 
conclude that the ^517 Application provides proper enablement 
and written description support for extracting the 
identification code „. when reception of the first (and 
subsequent) channel by the receiver begins . 

8 . '' Recording the Time When Reception by 
the Receiver is Ended ^' 

It is also my expert opinion that the person of 
ordinary skill in the broadcast signal technology art^. studying 
the ^517 Application, would conclude that, as of the time of the 
^517 Application's filing date, the specification provides 
proper enablement and written description support for recording 
the time that the reception by the receiver is ended. 

The reasons for this opinion are as follows . 

First, recording the time "when reception by the 
receiver ends" is recognized by those of ordinary skill in the 
art as being part of TV audience measurement systems at the time 
the subject application was filed. For example, the above- 
discussed 1987 U.S. Patent No. 4,697,209 teaches, "a signature 
is extracted each time an Event 2 (which includes television 
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receiver on and off events) is detected. The signature, as well 
as the times of occurrence of the signatures are stored to form 
a library of reference signatures." (Column 3, lines 58-63). 

Second, the ^517 Application clearly teaches that 
change-of-status events cause the recording of all available 
information: "block 516 (Fig. 7) logs as much detail as is 
available../' (See Page 48, second-to-last line.) Step 512 
clearly shows that "available information" includes time. That 
the receiver being turned OFF is a change-of-status event is 
evident to the person of ordinary skill in the art. 

Third, the Applicants have amended the specification 
to include disclosure from incorporated-by-ref erence U.S. Patent 
No. 5,481,294 (William Thomas and Daozheng Lu) . This disclosure 
(which I understand forms part of the originally filed 
application) clearly teaches that the disclosed audience 
measurement system records the time that the receiver undergoes 
an ON/OFF change. 

Accordingly, since the specification teaches that all 
'"available information" (including time) is recorded at change- 
of-status events, and since the specification also discloses the 
recording of the time that the receiver undergoes an ON/OFF 
change, it is my expert opinion that the ^517 Application 
provides proper enablement and written description support for 
recording the time that the reception by the receiver is ended. 

10 
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9. 


For the reasons set forth above, it is my expert 


opinion that the ^517 Application contains a written description 
of the invention (including the four features discussed above), 
and of the manner and process of making and using them, in such 
full, clear, concise, and exact terms as to enable any person 
skilled in the art to make and use the invention. 


information and belief are believed to be true; and further, 
that these statements were made with the knowledge that willful 
false statements and the like so made are punishable by fine or 
imprisonment, or both under Section 1001 of Title 18 of the 
United States Code. 


10. I hereby declare that all statements made herein 


of my own knowledge are true, and that all statements made on 




Michael A. Dolan 
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FOREWORD 

This standard was prepared by the Advanced Television System Committee (ATSC) 
Technology Group on Distribution (T3). The document was approved by the members of T3 on 
1 1 July 1996 as a full ATSC normative standard. The document was approved by the Members of 
the ATSC on [30 Aug 96]. 

1, SCOPE 

The Program/EpisodeA^ersion Identification (Program Identifier) standard provides a 
means of uniquely defining a program, episode, version, and source within the MPEG-2 syntax. 
The standard provides for a program identifier data packet that may be inserted into the Transport 
Stream at random intervals. A specific PID is assigned to the program identifier data packets that 
appear in the Transport Stream for each program. This PID is identified in the PMT. The 
program identifier packet contents may vary to allow specific identification of the separate 
component works (e.g. programs, commercials, and materials of a promotional nature) that make 
up the program. 

This document provides a detailed specification of the syntax required. A unique Program 
Identifier may be usefiil for program verification. 

2. REFERENCES 

The Program/EpisodeA/ersion Identification syntax is based on the ISO/IEC MPEG-2 
Systems Standard and is compatible with the requirements of the ATSC Digital Television 
Standard. 

ATSC Standard A/53 (1995), Digital Television Standard. 

ATSC Standard A/55 (1996) Program Guide for Digital Television. 

ISO/IEC IS 13818-1 International Standard (1994), MPEG-2 systems. 


3. DEFINITIONS 

3,1 Definitions 

With respect to definition of terms, abbreviations and units, the practice of the Institute of 
Electrical and Electronic Engineers (IEEE) as outlined in the Institute's pubhshed standards shall 
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be used. Where an abbreviation is not covered by an IEEE practice or industry practice differs 
frona IEEE practice, then the abbreviation in question will be described in Section 3.4 of this 
document. Many of the definitions included therein are derived from definitions adopted by 
MPEG. 

3.2 Compliance notation 

A used in this document, ^^shaW or "w///" denotes a mandatory provision of the standard. 
''Should' denotes a provision that is recommended but not mandatory. "May" denotes a feature 
whose presence or absence does not preclude compliance, that may or may not be present at the 
option of the implementer. 

3.3 Treatment of syntactic elements 

This document contains symbolic references to syntactic elements used in transport coding 
subsystems. These references are typographically distinguished by the use of the underscore (e.g. 
TS_program_map_section) and may consist of character strings that are not English words (e.g. 
uimsbf). 

3.4 Terms employed 

bslbf - Bit string, left bit first, where "left" is the order in which the bit strings are written in the 
Standard. Bits strings are written as strings of Is and Os within single quotation marks, e.g. '1000 
lOOr. Blanks within a bit string are for ease of reading and have no significance. 

Uimsbf - Unsigned integer, most significant bit first. 

Rpchof - Remainder polynomial coefficient, higher order first. 


4. PROGRAM/EPISODEA^ERSION IDENTIFIER 
4.1 Introduction 

In MPEG-2 System bit streams, the Program Map Table (PMT) PID for each program in 
the bit stream can be identified from PID 0. 

In the MPEG-2 and ATSC standards, the PID for each program bit stream must remain 
constant. However, a requirement to uniquely identify the component works (e.g. program, 
commercial, promo, etc.) used to assemble the program bit stream has been recognized. 

The method of unique identification employed in this standard assigns a 
program_identifier_descriptor to each work. The program_identifier_descriptor for each 
work shall be carried in a Program Identifier Table (PIT) within a Program Identifier Stream. 
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This Program Identifier Stream shall be identified in the PMT as described below. 

The stream_type shall be set to 0x85 (one of the ATSC reserved stream types). 

The elementary_PID shall indicate the FID nimiber carrying the Program Identifier Table 
(PIT). In this way the PID can remain constant for each program stream but the data packets 
carrying the unique identifiers assigned to the different component works that constitute the 
program stream can be inserted as required and when appropriate. This is similar to the method 
used to identify program related video and audio services, in that, video and audio packets are 
identified, as such, with the packets appearing as appropriate to support the service with the 
contents (payload) of the packets varying as appropriate. 

4. 2 The Program Identifier Stream 

The Program Identifier Stream consists of Transport Packets carrying 
program_identifier_table_section structures, each of which defme a PIT. The PIT is a general- 
purpose structure designed to carry one or more program-related structures. For the purpose of 
this standard, each instance of the FIT carries one registration_descriptor identifying the 
Registration Authority followed by one program_identifier_descriptor described below and in 
Section 4.4.* 

Table 1 Bit Stream Syntax for the Program Identifier 


Syntax 

Bits 

Format 

program_identifier_table_section() { 



table_id 

8 

OxDO 

section_syntax_indicator 

1 

'0' 

private.indicator 

1 

*r 

reserved 

2 

*ir 

private_section_length 

12 

uimsbf 


for (i=0: i<N, i++) { 
descriptor ( ) 

} 

CRC_32 32 rpchof 
J 

The FIT is carried in a single Transport Packet with a FID identified in the PMT_FID and 
obeys the syntax and semantics of the Private Section as described in Sections 2.4.4.10 and 
2.4.4.11 of ISO/IEC 13818-1. The following constraints apply to the Transport Packet carrying 
the FIT: 

FID shall have the value identified in the PMT_PID as described above. 
transport_scrambling_control bits shall have the value *00'. 


' A future standard could define, in a backwards-compatible way, additional descriptors. 
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adaptation_field_control bits shall have the value '01'. 
payload_unit_start_indicator shall be 1. 
pointer_field shall have the value 0x00. 

the remainder of the Transport Packet after the PIT section shall be padded with stuffing 
bytes of value OxFF. 


4.3 The Registration Descriptor 

The registration authority shall be the Society of Motion Picture and Television Engineers 
(SMPTE). A registration descriptor identifying SMPTE as the registration authority shall be 
carried in the PIT in conjunction with the prograin_identifier_descripton 

The registration_descriptor identifies the registration authority that assigns a block of 
numbers identified by the providerjndex to major content providers and/or distributors and 
individual prograin_event_id's to individual program events as appropriate. 


Table 2 Bit Stream Syntax for the Registration Descriptor 


Syntax 

Bits 

Format 

registration_descritor ( ). { 



descritor.tag 

8 

0x05 

descriptor_length 

8 

uimsbf 

format_identifier 

32 

0x0000 0034 

for i=0, i<N, i++ { 



additional identification info 

} 

} 

N*8 

bslbf 


Semantics of the fields are as follows: 


registration_descriptor - This ISO/IEC 13818-1 descriptor identifies the registration authority 
for the program_identifier_descriptor. 

descriptor_tag - This 8 bit unsigned integer field shall have the value 5, identifying this 
descriptor as a registration_descriptor. 

descriptorjength - This 8 bit unsigned integer field specifies the number of bytes of the 
registration_descriptor immediately following descriptor_length field. 

formatjdentifier - This 32 bit field identifies the registration authority that assigns the 
provider_index field within the program_identifier_descriptor and shall have the value 52 
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(0x00000034) which is the ISO/ITU number assigned to SMPTE. 
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4.4 Program identifier Descriptor 

The program_identifler_descriptor uniquely identifies a program (or a program 
segment) and may provide additional program details. The default condition, where the 
providerjndex is 0x0000 and the prograni_identifier_descriptor is 0x000000, is considered 
the null condition and may be used to reserve space in the data stream for possible future 
extensions. 


Table 3 Bit Stream Syntax for the Program Identifier 


Syntax 

program_identifier_descriptor ( ) { 
descriptor.tag 
descriptor_length 
provider.lndex 
p rog ra m_e ve nt_id 
episode_field_indicator 
episode_date_indicator 
ISAN_field_indicator 
reserved 

if (episode_field_indicator==1) { 
if (episode_date_lndlGator-=0) { 
episode.number 
version_nunfiber 
} 

else if (episode_date_indicator==1) { 
originaLdate_year 
original_date_month 
original_date_day 

} 

program_id_string_length 
program_id 

} 

if (ISAN_field_indicator==:1) { 
ISAN field 


Bits Format 


8 

8 

16 

24 

1 

1 

1 

5 


12 
12 


0x85 

uimsbf 

uimsbf 

uimsbf 

bslbf 

bslbf 

bslbf 

'00000' 


uimsbf 
uimsbf 


8 uimsbf 

8 uimsbf 

8 uimsbf 

8 uimsbf 

s*8 uimsbf ISO Latin-1 char. 


72 uimsbf 


Semantics of the fields are as follows: 


program_identifier_descriptor - This descriptor, in conjunction with the registration_descriptor, 
uniquely identifies the program and the event. 

descriptor_tag - This 8 bit unsigned integer field shall have the value 133 (0x85), 
identifying this descriptor as program_identifier_descriptor. (This descriptor_tag is one of 
the reserved tags in the ATSC Digital Television Standard, see section 5.7 in Annex C of 
ATSC A/53). 

descriptorjength - This 8 bit unsigned integer field specifies the number of bytes of the 
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program_identifier_descriptor immediately following descriptor_length field. The value 
shall range from 6 to 59 (0x06 to Ox3B). 

provider_index - This 16 bit unsigned integer field identifies the provider that assigns the 
program_event_id numbers for the block of numbers. The unique number is registered 
within the registration authority as identified by the registration_descriptor. This field shall 
have the same value as the provider_index field in the Channel Information Table of ATSC 
Standard A/55, "Program Guide for Digital Television. 

program_event_id- This 24 bit unsigned integer field identifies the program or product. 
The value of this number is assigned by the provider, as identified by the provider_index. 
The 24 bit field allows up to 16,777,216 unique programs per provider. This field shall 
have the same value as the program_event_id field in the Event Liformation Table of the 
ATSC Standard A/55, "Program Guide for Digital Television". A value of 0x000000 in 
association with provider_index value of 0x0000 indicates a null field. 

episode_field_indicator - This 1 bit flag signals the existence of the episode_number and 
version_number or the episode date fields, and the program_id_string. If the 
episode_field_indicator = 0 then those fields do not exist. In this case 
episode_date_indicator shall be set to 0. 

episode_date_indicator - This 1 bit flag signals the use of the 24 bit episode field. If the 
episode_date_indicator = 1, then the episode field is used to indicate the date of first 
presentation (original__date) year, month, and day. If the episode_date_indicator = 0, then 
the 24 bit episode field is used to indicate an episode (fu"st 12 bits) and a version of the 
episode (second 12 bits). 

ISAN_field_indicator - This 1 bit flag signals the existence of the ISAN_field. ISAN 
(International Standard Audiovisual Number) is a identification system used for certain 
audio/visual properties (see description of ISAN_field, below). 

episode_number - This 12 bit xmsigned integer number identifies the episode number of 
the production (1 to 4095 mclusive). Default = 0x000. 

version_number - This 12 bit unsigned integer number identifies the version of the 
production or episode (1 to 4095 inclusive). Different versions of the program/production 
may be assigned for different languages, program lengths, different titles for the same 
program/product, etc. For instance, a film product may be released as a 120 minute 
version in English for North /American theatrical release, a 180 minute version in French 
for European theatrical release, and a 1 10 minute release in English and French for use on 
Canadian television. Default = 0x000. 

original_date_year - This 8 bit unsigned integer number represents the offset from 1900 
to the year of first presentation. (Year minus 1900: e.g. if first presentation was 1984, the 
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original_date_year would have a value of 84 or 0x54). 

original_date_month - This 8 bit unsigned integer number represents the month of the 
year of first presentation. (1: January - 12: December). 

original_date_day - This 8 bit unsigned integer number represents the day of month of 
first presentation (1-31). 

program_id_string_length - This 8 bit unsigned integer number represents the length of 
the optional program_id_string to follow. The length may range from 0 (indicating a null 
string) to a maximum of 40. 

prograiii_id_string - A sequence of zero to 40 characters which represent a human- 
readable version of the Program Identifier. The characters are coded according to 
ISO/IEC 8859-1 (Latin-1). The program_id_string is not intended for display or 
processing by consumer equipment; it may be provided by the creator of the 
program_id_string as a human-readable reference check on the Program Identifier. 

ISAN_field - The 9 byte optional field may be used to cross-reference the ISAN number 
for the program when one exists. ISAN is an identification system used for certain 
audio/visual properties. It consists of a 16 digit integer number coded in bed (binary- 
coded-decimal) notation in a 64 bit (8 byte) string. The most significant byte of the 
ISAN_field is used to carry the ISAN registration authority eight bit value. 


4.5 STD Model for the Program Identifier Streams 

The program identifier streams are assigned stream_type 0x85 and use the same format as 
the private section of ISO/IEC 13818-1 (with stream_type = 0x05) including the 32 bit CRC field. 
The following constraints shall apply: 

The Program Identifier Stream shall adhere to an STD model that can be described by an 
MPEG-2 smoothing buffer descriptor (Section 2.6.30 in ISO/IEC 13818-1) with the 
following parameters: 

sb_leak__rate shall be 3 (indicating a leak rate of 1200 bits/s). 

sb_size shall be 512 (indicating a smoothing buffer size of 512 bytes). 
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ANNEX A 


Informative 


GUIDE AND PRACTICE 


1. INTRODUCTION 

There is a requirement for a standard mechanism that provides a unique program (or 
production) identifier within the MPEG-2 transport. The MPEG standard 13 bit packet 
identification field (FID) provided for in the syntax is limited in the number (8192) of unique 
values. Further there is no restriction on how numbers may be assigned and reassigned by original 
producers and/or the end service providers. In fact, a single video broadcast service should assign 
the same FID number to all segments (programs, commercials, and promos) provided as part of a 
single program service stream to assure undisturbed continuity of display at the receiver. This 
results in there being a strong probability that different program content provided by different 
producers and service providers will be distributed using the same FID value. Unique identifiers 
are essential as they provide a mechanism that assists in the verification of clearance, automated 
program selection and recording, and protection of intellectual property rights. 

MFEG anticipated such a need and provided tools within the Transport Layer syntax. The 
Frogram Map Table (FMT) allows for inclusion of program stream descriptors which allow 
additional description of each program contained in the table or to pointers to data packets that 
contain additional information. 

The Frogram/EpisodeA/ersion Identification (Frogram Identifier) standard provides a 
means of uniquely defining a program, episode, and version and uses the latter technique. 

2. APPLICATION 

The descriptor provided for in this standard allows for the unique identification of each 
version of an episode or program or production using a 64-bit code. The code is divided into 
three fields consisting of a 16-bit provider_index, a 24-bit program_event_id, and a 24-bit 
episode and version identifier. 

A 16-bit provider_index allows for 65,536 different blocks of 24-bit program_event_id 
numbers. This 16 bit unsigned integer field can be used to identify the original provider that 
assigns the program_event_id numbers for the block of numbers. 
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The 24-bit prograin_event_id field combined with the 16-bit provider_mdex uniquely 
identifies the program or product. The 24 bit field allows up to 16,777,216 unique programs per 
provider Jndex block for a total of >1.099 x 10*^ (65,536 x 16,777,216). 

The third field is an optional field of 24-bits that can be used to indicate either the date of 
the first presentation of the program or production (as might be desirable for use with news 
programming) or it can be used to indicate an episode and/or a version of the production. The 
field allows up to 4095 episodes of the program or production to be identified with up to 4095 
different versions of each episode or production. 

3. ASSIGNMENT OF PROVIDER.INDEX AND PROGRAM_EVENT_ID 

The assignment of providerjndex and program_event_id numbers is controlled by the 
registration authority. The registration authority is the Society of Motion Picture and Television 
Engineers (SMPTE) located at 595 West Hartsdale Avenue, White Plains, New York 10607-1824 
(Telephone: +1 (914) 761-1100), HTTP://www.smpte.org. The standard allows the registration 
authority to assign one or more of the 65,536 provider_index numbers to major producers who 
in turn will assign program_event_id numbers to the individual program segments that they 
produce, distribute or otherwise administer. The registration authority may also reserve some of 
the provider_index numbers for its own administration. In this case the registration authority 
may assign program_event_id numbers fi-om these reserved blocks to individual program events 
where the source is organized to produce a single event or where the source wishes to remain 
anonymous. Altematively, the registration authority may partition the 24-bit program_event_id 
numbers firom some of those reserved blocks into sub-blocks and assign them separately to a 
multiplicity of providers who do not require the full range of 16,777,216 program_event_id 
numbers that are available with each provider_index number. 

The registration authority (SMPTE) provides a list of all prograin_event_id numbers it 
assigns with the name of the producer and the descriptive material found in the 40 character 
program_id_string (see Section 6 below). 

The 40-bit unique identification number (provider_index -f program_event_id) can be 
assigned to the production or program either at the inception of the production, at the completion 
of the production, just prior to distribution, or at such time as the rights holder or the rights 
holder's agent deems appropriate. The production or program carries that unique number 
throughout its life regardless of change of rights holder, distribution mechanism, or the creation of 
different versions. (The method of handling different versions of the product is described in 
Section 5 below). 

In summary, once a unique identification number is assigned to a production, it does not 
change even if there is a change in ownership. 
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4. TRACKING THE ASSIGNMENT OF PROGRAM_EVENT_ID_NUMBERS 

The agreement between the registration authority (SMPTE) and other parties that are 
assigned provider_index numbers should provide for the other parties to list all 
program_event_id numbers that they assign with the descriptive material found in the 40 
character program_id__string and to provide updated copies of the list at regular intervals either 
electronically or in hard-copy form to the registration authority. 

The agreement should also provide a mechanism for the registration authority (SMPTE) 
to administer the provider_index block should the original other party either wish to give up its 
responsibilities or otherwise be unable to administer its responsibilities. 

5. HANDLING OF DIFFERENT VERSIONS 

The 12-bit version_field provides for up to 4095 different versions of the same episode or 
program or production and provides for identification of different program lengths, usage of 
different languages, products with different ratings, and alternate titles for different markets. For 
instance, a film product may be released as a 120 minute version in English for North American 
theatrical release, a 180 minute version in French for European theatrical release, and a 110 
minute release in English and French for use on Canadian television. The 40-bit unique identifier 
is intended to tie all of the versions together for traceabiUty. 


6. PROGRAM_ID_STRING CONTENTS 

The contents of the 40 character prograin_id_string may be assigned by the original 
producer and are available as a hxmian-readable version of the Program Identifier. The 
program_id_string is not intended for display or processing by consumer equipment, but may be 
usable in broadcasting or studio equipment to verify that the selected Transport Stream contains 
the proper program components. 


7.1 The registration_descriptor and the program_identifier_descriptor together provide the 
syntax for the imique identifier and are intended to be used together. 

7.2. The intention is to never to reuse the 40-bit unique identification number (provider_index + 
prograin_event_id) at least, within the first 150 years of use. 


7. USAGE 
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7.3 It is suggested that the packets containing the unique identification number appear early in 
the Transport Packet data stream and at regular intervals thereafter on the order of once every 30 
seconds to 2 minutes. It is further recommended that in each instance, the packets be repeated 
twice at 0.5 second intervals thereafter as an assist in verification during times of interference. 

7.4 It is suggested that in the case of commercials and other program streams containing 
promotional materials, the packets containing the unique identification number appear in the 
Transport Packet data stream toward the end of the work, starting at 2 or 3 seconds from the end 
and be repeated twice at 0.5 second intervals thereafter as an assist in verification during times of 
interference. 

7.5 It is understood that there is nothing in this standard that requires consumer equipment to 
address the Program Identifier Stream packets or to decode the packets. However, consumer 
equipment that provides a Transport Packet data port should pass the Program Identifier 
Stream through the port with the remainder of the program (video, audio, and data) information. 
Since the Program Identifier Stream provides unique identification of the work, recording of 
the program should include the unique identifier. 

7.6 Some parties had suggested that the time-to-show be included, but this is a distribution issue 
(varies with local broadcaster), is covered in the program guide, and has not found wide 
acceptance. 

7.7 Users are advised not to assign bits for "intelligence" (i.e. first bit is for national commercials, 
following six bits identify program length, etc.), this information can be found in a program guide 
or in extension bits; and could be used by others to automate the removal of commercials and 
other content of a promotional nature. 

8. ADMINISTRATION 

8.1. SMPTE is the registration authority for the unique product identifier. SMPTE is an 
international organization comprised of individual members in 72 countries. SMPTE serves the 
ISO as the Chair and the Secretariat for TC 36 (cinematography). SMPTE serves the lEC as the 
U.S. Technical Advisor and TAG Administrator for lEC SCIOOB (recording). SMPTE is 
recognized by the American National Standards Institute as the standards developer for television 
production and motion pictures. SMPTE has been serving the international community since 1916 
and has an established presence. SMPTE members represent a broad range of disciplines 
representing the film, terrestrial broadcasting, cablecasting, direct broadcast, and common carrier 
industries. SMPTE is, therefore, industry and politically neutral. 

8.2. Each block of numbers identified by provider_index number is assigned to program/content 
providers or to SMPTE to manage. SMPTE plans to establish mechanisms to provide registration 
services accurately and as part of a range of services already provided to the specific community 
targeted by the standard. 
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8.3 SMPTE intends to provide an active listing via the Internet of the 16-bit provider_index 
numbers with a cross reference to the institution managing the individual provider_index block. 
This would likely include a hyperlink capability to the Web page of the institution managing the 
block to allow access to the 24-bit program_event_id listings within the block. For those blocks 
managed directly by SMPTE, the hyperlink access to the individual program_event_id listings 
would be obvious. 

8.4 SMPTE and institutions wishing to manage individual blocks of program_event_id numbers 
should update the listings no less than once per business day. 

8.5 For each work assigned a program_event_id, the hyperlink accessible listing should cross 
reference the name of the work, episode number, version information and any other descriptive 
material found in the 40 character program_id_string. 
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